Generating things from UML Models... Design Notes Only; Not Yet Implemented
Design Overview
Generation is done by an aspect added into a generic UMLModel component.
Each UML Element class (Classifier, AssociationEnd, Attribute, etc.) has
a generate() method which will return a Template for the respective
element of the UML model. In general, UML elements derived from
Namespace will call the generate() methods of their ownedElements
and install the results in their own output template, but precisely
which ownedElements they use, may vary from element type to element
type.
The framework tries to keep semantic interpretation to a minimum,
focusing instead on mapping metadata into a component specification.
For example, rather than try to interpret TaggedValues or convert them
into attributes, they are simply placed into a data structure that
a Builder can later interpret. This means that horizontal frameworks
can easily incorporate their own specialized uses of TaggedValues
without requiring any extensions/alterations to the basic generator
framework.
For now, the generation aspect's focus is on packages, classes,
attributes, associations, tagged values, and stereotypes. Support for
other types of objects may come later. To support these basic types,
only a few semantic interpretations are necessary:
Base classes - generalization relationships must be interpreted to
specify a template's base classes
Note: naming rules must be established so that the generating
class knows to refer to bases by fully qualified names, partial
names, etc. Most likely this could be implemented through a
"generation context" object passed around among generate()
methods, perhaps with a getGlobalNameForClass() method to
implement the naming policy.
Does UML actually have any way to determine ordering of base
classes??? Eeek...
Service-Element-Feature options, controlled by TaggedValues
Whether a class specifies Service, Element, or both
How do we reference Element from Service and vice versa?
Will we have problems with having two outputs for one input?
Note that associations & attributes need to reference a
service rather than an element, so they need to know
a thing's service name. Ugh. Perhaps a TWServiceName
ComputedFeature is the answer. Name munging will also
need to occur.
Any name mapping for the Service (e.g. "Vertex"->"Vertices")
It may be that we can also have the policy object control
things like default bases in the absence of explicit bases..
TaggedValues and StereoTypes
Interfaces
Should we create scarecrow interfaces?
Should realizations create __implements__ relationships?
Should realizations imply anything else? (E.g. being an Element
or Service)
Misc.
Policy Object
Things to be handled by the policy object:
Creation of a template object for a given generate() (based on
source object, TaggedValues, base class names, and default
"flavor")
Naming of references to other elements
|